The present invention is directed to the field of testing computer programs, and, more specifically, to automated testing.
Call centers have become a popular means for providing operator and customer services for businesses. A call center is a logical organization of telephony resources that serves as a focal point for receiving customers"" telephone calls and for providing manual or automatic services to callers in response to such calls. A service may be, for example, operator services provided by a phone company for special feature calls, or customer services provided by a manufacturing company for a product they offer.
In many call centers, computers, often in the form of operator consoles and audio response units, are used to automate many services. Service applications are software programs that run on these computers and provide automated services. Like other software programs, these service applications are continuously under development and require frequent testing. Each new service or product offered, or enhancement to an existing service or product, requires that new versions of each application that runs on call center computers be developed and tested. One necessary component of testing includes regression testing. Testing a new version of a service application involves testing the functions performed by previous versions and is called xe2x80x9cregression testing.xe2x80x9d
For example, if a service application is executed on an operator console to process a collect call, and a new feature is added to the collect calling service, then a new version of the service application must be developed that provides the new feature. In addition to testing for the capabilities required for the new feature, this new version must also undergo regression testing to ensure that it can correctly provide the features provided by the previous version, since it would not be acceptable for the new version to function properly in servicing the new feature of the collect calling service, but fail in servicing the existing features.
Conventional methods for regression testing of new service applications require that a new testing system be developed for each new version or xe2x80x9crelease,xe2x80x9d of an application, which can quickly become very cumbersome and expensive. Other conventional regression testing methods record user input and screen displays of applications in process, and then replay these for new releases to regression test. However, these testing applications are generally intrusive, interrupting the processing of the service application at various points. Also, because these testing limitations are limited to recording user input and screen displays, they could not capture many kinds of data and processes that were vital to complete testing, such as background processing, database queries, and internal data writes.
The present invention performs automated testing of service applications using automatically generated logs, so that new testing applications need not be created for each new release of a service application. Additionally, as a distinct improvement over conventional testing techniques, the invention tests all aspects of the service application by accounting for all data and processes performed, and does so without interrupting the processing of the service application.
An Automated Regression Tester (ART) provides a toolkit in the form of an Application Program Interface (API) that can be used to build testing capabilities into the service application itself. The API is a group of functions called by the service application to report all of the data and activities generated during the processing of the service application. This API records this information to a test log for comparison to the data and activities generated when processing the same call with a new version of the service application.
When a new service application is first developed, it is loaded and executed on the computer (such as an operator console or audio response unit (ARU)) for which it is designed. The service application processes a call from the time a call reaches a call center to the time the call is released from the call center and the operator console or ARU creates a billing record for the call.
While processing a call, the service application performs various related activities, such as displaying screens prompting the user (i.e., operator) for input; reading input from the user, the caller and the network; performing function calls; interfacing with external systems; and creating and writing to data records. The user or tester performs call processing functions as would be done for an actual call in a production environment. These functions include, for example, placing a live call to the operator console or ARU over an actual network and entering input at the operator console.
Throughout this entire process, the service application, through the API provided by the present invention, records to a test log all the data and activities generated by the service application and its environment. The information recorded includes caller input, operator input, background processing, and network data generation. This log represents a test scenario, and provides the input that will be needed to test future versions of the service application under the same test scenario. Several different test logs, representing different test scenarios, may be generated for a service application""s processing of a single type of call. The different test logs generated may represent the different ways a call can be handled, and/or different points of failure in the call flow.
When a new version of the service application has been developed, to add a feature to the current version or to port the current version to another computer system or operating system, for example, the ART can automatically apply the test logs generated in response to user interaction against the new version of the service application to regression test the new version. The new version of the service application and the ART are executed on separate components of the call center. The ART automatically dials a call to the operator console or ARU, using data from the test log. The ART then begins interacting with the service application that is running on the operator console or ARU, and emulates all environmental processes, including caller, operator, and network input. The ART again logs the output of the service application that is produced by the API inserted into the service application, and produces a second test log representing the processing of the new version of the service application.
The ART can then compare the second test log with the first test log and determine if the new version performed in the same manner as the old version. Any discrepancies will be due to either a bug in the new version, or an intended change in functionality in the new version that would not be reflected in the first test log. These discrepancies are presented in a report to the user or tester, who can then determine whether any bugs exist in the new version. Any discrepancies due to an intended change in functionality in the new version are easily identified. The user or tester can then record new data over these discrepancies to create a new test log that can be used for regression testing on yet future versions.